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appropriate functions from the ground to 
the spacecraft. 


Abstract 

The conflict between increases in space 
mission complexity and rapidly declining 
space mission budgets has created strong 
pressures to radically reduce the costs of 
designing and operating spacecraft. A key 
approach to achieving such reductions is 
through reducing the development and 
operations costs of the supporting 
mission operations systems. 

One of the efforts which the 
Communications and Data Systems 
Division at NASA Headquarters is using 
to meet this challenge is the Mission 
Operations Control Architecture (MOCA) 
project. Technical direction of this effort 
has been delegated to the Mission 
Operations Division (MOD) of the 
Goddard Space Flight Center (GSFC). 

MOCA is to develop a mission control 
and data acquisition architecture, and 
supporting standards, to guide the 
development of future spacecraft and 
mission control facilities at GSFC. The 
architecture will reduce the need for 
around-the-clock operations staffing, 
obtain a high level of reuse of flight and 
ground software elements from mission 
to mission, and increase overall system 
flexibility by enabling the migration of 


The end results are to be an established 
way of designing the spacecraft-ground 
system interface for GSFC's in-house 
developed spacecraft, and a specification 
of the end to end spacecraft control 
process, including data structures, 
interfaces, and protocols, suitable for 
inclusion in solicitation documents for 
future flight spacecraft. A flight software 
kernel may be developed and maintained 
in a condition that it can be offered as 
Government Furnished Equipment in 
solicitations. 

This paper describes the MOCA project, 
its current status, and the results to date. 


Introduction 

Most current spacecraft are extensively 
supervised from the ground, and 
spacecraft command and control systems 
have been re-invented by almost every 
new flight mission. This seriously affects 
ground systems reusability, and therefore 
costs for systems development, training, 
software maintenance, and sharing of 
operators among projects. This traditional 
approach is in serious conflict with the 
realities of declining space mission 
budgets. 
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The Communications and Data Systems 
Division at NASA Headquarters, through 
the Mission Operations Division (MOD) 
of the Goddard Space Flight Center 
(GSFC), is addressing this problem by 
sponsoring the Mission Operations 
Control Architecture (MOCA) project. 
The objective of this program is to 
develop a spacecraft control and data 
acquisition architecture which will guide 
the development of future spacecraft and 
mission control facilities. The architecture 
is intended to reduce the need for around- 
the-clock staffing of operations control 
centers (partly by increasing spacecraft 
autonomy), enable a high level of reuse 
of both flight and ground software from 
mission to mission, and allow the 
allocation and migration of functions 
between ground and spacecraft missions 
as is appropriate for a given mission 
requirements set. 

MOCA is using a three pronged 
approach: deep involvement of the 
ultimate implementing and operating 
community at GSFC; analysis of current 
mission operations systems, leading to a 
redefinition and standardization of 
architecture; and a survey and assessment 
of available technologies, subsystems, 
and commercially available products, 
with analysis of how to make it all fit 
together. 


Organization and Process 

In order to provide a broad base of 
knowledge and to enhance the ease of 
acceptance of results, the MOCA project 
is being conducted by the MOD as a 
cooperative effort among itself, the 
GSFC Flight Projects Directorate, and the 
GSFC Engineering Directorate. The latter 
is the GSFC's flight systems engineering 
organization. The organizational tools 
used to implement this cooperative 
structure are an ad hoc MOCA Steering 
Group, with members from management 
from NASA Headquarters and from each 
of the three directorates, and a MOCA 
Users Forum, which is constituted 
primarily of selected, experienced. 


engineering level persons from each 
organization. 

MOCA is divided into two phases, the 
Exploratory Phase (which began in 
February, 1994) and the System Design 
Phase. Each phase will last from one year 
to eighteen months, as required. The 
Exploratory Phase is a rapid but in-depth 
survey of the complexity and scope of the 
problem and an examination of potential 
solutions. The System Design phase will 
both develop and deploy the new 
capabilities required for the system. 

When agreement on the architecture is 
achieved, one or more spacecraft will be 
selected to use as a prototype to finalize 
and prove the data structures, protocols, 
and interfaces between modules defined 
by the architecture. Ultimately, flight 
software elements and corresponding 
ground control modules will be 
developed, maintained, and 
configuration-controlled by an inter- 
directorate team. Therefore, the MOCA is 
an architecture, a set of interface 
definitions, supporting protocols and 
application layer languages, that enable 
the standardized commanding and 
supervision of remote space vehicles. 

As this work progresses, it will be 
presented to the American Institute of 
Aeronautics and Astronautics (AIAA) 
Spacecraft Control Working Group. It is 
hoped that a NASA or U. S. Government 
agreement on an architecture for 
spacecraft control and a suite of 
supporting standards will result through 
this channel. However, the MOCA 
project focuses on the needs of GSFC 
specifically. 


Approach 

The aim of MOCA is to substantially 
reduce the end-to-end life cycle cost of 
future flight programs by radically 
reducing ground operations costs, 
including development costs. 
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MOCA disputes the contention that 
"cheap programs mean dumb spacecraft". 
Instead, MOCA asserts that when the 
end-to-end life cycle costs of a program 
are considered, "cheap programs need 
smart spacecraft". MOCA further 
contends that the technology is currently 
available to have smart spacecraft at very 
little increase in development cost, and 
that in fact most of the basic enabling 
technologies (for example, increased 
computational power, increased memory, 
large solid state data storage) are already 
in flight use. And that therefore what is 
required to achieve the mission operations 
cost reduction objectives are the 
development and implementation of the 
necessary operations concepts, 
architecture, and standards. 


Preliminary Functional Architecture 

The following is very preliminary, and 
will undoubtedly undergo major changes 
as the MOCA project matures. 

The context of MOCA is "Mission 
Operations Functions", as shown in 
Figure 1. Therefore the figure shows the 
external interfaces to MOCA. There are 
two fundamental points made by the 
figure. First, it is important to note that 


mission operations functions are the 
domain, regardless of whether the 
functions are performed on the spacecraft 
or on the ground. Second, and equally 
important, flight subsystems and ground 
supporting subsystems are not in the 
MOCA domain, but the interfaces with 
them (and therefore the relevant functions 
performed by them) are. 

The primary driver of mission operations 
is the science planning entity which 
provides both strategic planning 
information (the science plan) and part of 
the detailed or tactical planning inputs 
(instrument commands). These inputs 
are provided in cycles of various time 
intervals. 

The MOCA functions and processes use 
these inputs to plan and schedule 
resources, coordinate the execution of the 
plan across the resources, monitor and 
assess the status of the resources, and 
feedback lessons learned into the process 
for the next cycle. Since the MOCA 
functions operate in this cyclic manner, 
the architecture described in this paper 
decomposes the MOCA functional 
architecture based on this planning- 
execution- assessment nature of mission 
operations. Figure 2 depicts the three 
functions which make up the First level of 



Figure 1: MOCA External Interfaces 
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the MOCA functional architecture. Also MOCA functions. This paper will not go 

shown in Figure 2 are two entities utilized into detail on these lower level 

by all three functions: the Mission Model representations except to note that the 

and the Mission Database. Scheduling and Planning and the 

System/Subsystem Analysis functions 
The Mission Model constitutes an have been further decomposed based on 

accurate representation of all the short term and long term processes, 

resources the MOCA functions have 
visibility into and interaction with. The 

Mission Database is a repository of actual Preliminary Target Characteristics 

data points either used or generated by the 

mission model and MOCA functions. All A preliminary analysis of current mission 

three of the primary MOCA functions use operations has lead the MOCA to identify 

these resources but in unique and the following as highly desirable 

different ways. For instance, the characteristics which should be included 

Planning and Scheduling function uses in the MOCA concept of operations, and 

the Mission Model to predict the events enabled by the MOCA architecture. These 

and actions of resources for the next are very early ideas, and will undoubtedly 

cycle. The Mission Command and be subject to significant modifications, 

Control function uses the Mission Model expansions, and deletions as the project 

to compare the real time events and progresses, 

actions of resources against the predicted 

events and actions to ensure operations It appears highly desirable to minimize 

are proceeding as planned and within the number of contacts between a 

spacecraft and the 
ground, as is 
feasible within the 
constraints of 
mission safety and 
mission 

performance. The 
planning, 
scheduling, 
initiation, conduct, 
and termination of a 
space/ground contact 
is expensive in 
itself, and the cost is 
much more sensitive 
to the number of 
contacts than to 
duration or data 

Figure 2: First Level MOCA Functions rates. This 



tolerances. The System/Subsystem 
Analysis function uses the mission model 
to determine why events and actions did 
not perform as predicted and to provide 
feedback into the model as resources 
degrade or change over the life of the 
mission. 


minimization should 
be accomplished by making spacecraft 
more autonomous than at present. The 
feasibility and acceptability of increased 
autonomy should be realized by 
designing the process of achieving 
autonomy to reduce risk, minimize life 
cycle costs, and maintain flexible control 


Figures 3 through 5 show the next level 
of decomposition for the three primary 


of the process by project management. 
The process should include the 
development of ground based backup 
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capability to onboard functions, and by 
achieving the autonomy via function 
migration from ground to space as 
operational experience is gained. 

Spacecraft should be made to look 
operationally as much alike as possible. 
Through the use of interface, format, and 
procedural standards to implement a 
"virtual spacecraft" concept, spacecraft 
should be made to appear to the ground 
systems as operationally identical as is 


example of such existing standards are 
the tailored communications standards 
that can be adopted from other non- 
MOCA sources (e.g. Consultative 
Committee for Space Data Systems 
(CCSDS), Space Communications 
Protocol Standards group (SCPS)). Other 
standards, such as for the operations 
functions (i.e. at the Application Layer) 
will be selected by or developed within 
MOCA. 
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Figure 3: Functional Decomposition of the MOCA 
Planning and Scheduling Function 


feasible. This will eliminate large parts of 
development and training costs, allow 
operations crews to be shared among 
several spacecraft, and increase the 
reliability of operations. 

Standards should define all operational 
interfaces. Standards should be selected, 
adapted, or, as necessary, developed and 
emplaced at all operational interfaces. An 


The Standards should be used across 
different projects. To achieve the above 
targets, the same standards must be used 
for each flight project. This approach 
minimizes the non-recurring ground 
system development and modification 
costs as well as substantially reducing 
recurring mission operations costs. 
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Implementation of the MOCA concepts, 
architecture, and standards should be 
accomplished to the maximum extent 
possible through the use of existing 
standards, existing technologies, work 
accomplished by other similar NASA and 
Department of Defense activities, 
commercial off-the-shelf products, and 
through use of existing testbeds and flight 
opportunities for proof of concept and 
validation. Major redesign efforts and all 
new development for control facilities at 
GSFC should be accomplished in 
conformance with the MOCA standards. 


The Future 

Although MOCA is still in an early phase, 
several key concepts are beginning to 
emerge which appear to be technically 
feasible and economically desirable. 
Among these are: communications 
between ground systems and spacecraft 
by an intermediate or high level process 
control language, rather than by 
commands and telemetry; on-demand 



Figure 4: Functional Decomposition of the MOCA 
Mission Command and Control Function 
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space/ground communications by 
spacecraft demand ; and eventually a 
reversal of current roles in that a 
spacecraft may view its supporting 
ground systems as a collection of on-call 
resources to help it meet its mission 
objectives. 


It appears at this time that there are no 
insuperable technical or cost hurdles to 
achieving greatly decreased end-to-end 
life-cycle mission operations costs 
through the techniques of increased 
spacecraft autonomy, appropriate 
standards for critical operations 
interfaces, and standard protocols, all 
structured by a common mission 
operations architecture. 
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